Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/dhc/dhc-minutes-93mar.txt

Text File | 1993-04-28 | 4.0 KB | 95 lines

CURRENT_MEETING_REPORT_


Reported by Ralph Droms/Bucknell

Minutes of the Dynamic Host Configuration Working Group (DHC)

The Working Group discussed the interface between DHCP and the Domain
Name System (DNS). DHCP needs an interface that can allow dynamic
updates to DNS entries in response to dynamic allocation of DNS names to
DHCP clients.  Rob Austein explained that the DNS Working Group is
currently developing such an interface to DNS that considers the needs
of DHCP.

The Working Group discussed the possible use of SNMP with DHCP. SNMP may
be useful as a ``second-level'' bootstrap mechanism to transmit
additional configuration parameters to a client.  SNMP is not likely to
be as useful as an implementation-specific interface for server
management.  SNMP is an interesting candidate for the server-server
protocol, as it may provide the semantics and data representation tools
required for exchange of DHCP binding information between servers.

The Working Group discovered a technical problem with the current
definition of the `chaddr' field, which provides for use of `chaddr' as
either a hardware address or other unique identifier.  As the `chaddr'
value must be used to return DHCP reply messages to the client, that
field will be reserved for use strictly as a hardware address, and the
client will be required to supply a unique identifier in a `client
identifier' option.  This identifier will be a typed value with the same
structure as defined for the `chaddr' field.

Mike Carney and Jon Dreyer submitted a new definition for encapsulating
vendor-specific options that the Working Group accepted with minor
modifications.  In the accepted definition, the `vendor- specific
information' option will include an initial value that identifies how to
interpret the contents of the option, and other DHCP options, encoded in
the same format as the current variable- length DHCP options.  The
initial identifying values will be centrally administered to avoid
conflicts.  One identifying value will be reserved for local use.

The mechanism for determining the parameters returned to a particular
client was discussed at length.  The focal points of the discussion were
the ways in which a client can identify its characteristics (`client
type' option) and the rules by which a server can use those
characteristics to choose the information to be returned to a host.  No
conclusion was reached at the meeting; an interim solution will be
incorporated into the DHCP specification Internet-Draft to allow the
protocol to move forward to Proposed Standard.

Attendees

Kannan Alagappan         [e-mail]
Steve Alexander          [e-mail]

                                   1





Philip Almquist          [e-mail]
Robert Austein           [e-mail]
John Boatright           [e-mail]
Gregory Bruell           [e-mail]
Ralph Droms              [e-mail]
Robert Gilligan          [e-mail]
Richard Harris           [e-mail]
John Hascall             [e-mail]
Roland Hedberg           [e-mail]
Ronald Jacoby            [e-mail]
Scott Kaplan             [e-mail]
Frank Kastenholz         [e-mail]
Mark Kepke               [e-mail]
Andrew Knutsen           [e-mail]
Lakshman Krishnamurthy   [e-mail]
Yu-Lin Lu                [e-mail]
Paul Lustgraaf           [e-mail]
Kent Malave              [e-mail]
Glenn Mansfield          [e-mail]
Evan McGinnis            [e-mail]
William Nowicki          [e-mail]
William Owens            [e-mail]
Charles Perkins          [e-mail]
Steven Richardson        [e-mail]
Shawn Routhier           [e-mail]
Jon Saperia              [e-mail]
Chris Shaw               [e-mail]
Marek Tomaszewski        [e-mail]
Walter Wimer             [e-mail]



                                   2